Various types of graphical models and methods are used extensively in the modeling of computations, algorithms and operations that can be performed on computational hardware devices, such as a computer, microcontroller, FPGA, and custom hardware. Graphical modeling can be used for the design, analysis, code generation, and synthesis and testing of many systems, including dynamic and engineered systems. Types of such graphical models include time-based block diagrams such as those found within Simulink® from The MathWorks, Inc. of Natick, Mass., state-based and flow diagrams, such as those found within Stateflow® from The MathWorks, Inc. of Natick, Mass., data-flow diagrams, circuit diagrams, and software diagrams, such as those found in the Unified Modeling Language. A common characteristic among these various forms of graphical models is that they define semantics on how to execute the graphical model. For example, a block diagram model provided by Simulink® can be processed via a model compilation process to convert the model into an executable form. The executable form of the block diagram model can then be executed to simulate the model over a span of time. The simulation uses information provided by the system's representation in the block diagram model to simulate the system behavior of the model.
Graphical models can be used to solve complex engineering and scientific problems by developing mathematical models that simulate the problem. Graphical modeling environments can provide an extensive set of building blocks that represent mathematical operations, logic constructs, and other specific modeling and design tasks for modeling, simulating, and testing a wide range of dynamic systems. A model is prototyped, tested and analyzed by running the model under multiple boundary conditions, data parameters, or just a number of initial guesses. Many engineering and scientific problems require larger and more complex modeling. For example, graphical modeling may be used to model, design and simulate the many systems integrated into an aircraft or automobile. With the types of problems that can be modeled and simulated in a graphical modeling environment, graphical models have reached a remarkable level of complexity, and so has the simulation of such models.
Graphical models, such as a block diagram model, can be hierarchical and reference and organize a multitude of graphical models each representing an additional system. In turn, these referenced graphical models may also be large or complex, and also may reference additional graphical models. In this manner, a top view of a hierarchical block diagram model can provide a high-level view of the system with one or more blocks of this top view each representing a sub-system block diagram model. One can drill down into the subsystem view from the top level to view the details of this sub-system model. The block diagram model of the sub-system can also include a multitude of blocks, and in turn, some of these blocks may represent additional block diagram models and details of further sub-systems. As such, a hierarchical model may be constructed with hundreds or more block diagram models in a multitude of levels with hundreds of thousands of blocks representing primitive and aggregate computations, algorithms, and operations.
In the design of graphical models, partitioning of the model and design tasks may be necessary considering the design and development of the overall system on a large project is beyond the capability of a single designer or engineer. Partitioning of the design tasks allows multiple engineers and designers, or groups or teams of engineers and designers to work on portions of the system design. This can be facilitated through partitioning of the system graphical model into a hierarchy of multiple models representing portions or sub-systems of the overall system. Each sub-system model may be considered to be a unit model that may be independent of or dependent on other unit models. Each engineer or teams of engineers can focus on the design of one or more of these unit models. The overall system model then includes the combination and integration of all the unit models to form the overall system model.
With respect to design, the partitioning of models in a hierarchical manner facilitates teams of engineers to design complex models that may have hundreds of thousands of blocks. However, the overall graphical model needs to come together as a whole to be compiled into an executable form for execution of the entire system. Execution is used to determine and test the behavior of the system as designed by the aggregate of the graphical models. The compilation of a model with hundreds of thousands of blocks can be a task of significant size and complexity. As the size and complexity of the model increases, the model compilation process also becomes more resource intensive and time-consuming. The time and resources needed to compile a large or complex model is further compounded by the fact that execution and modeling is intended to be an interactive and iterative process. A graphical model is processed into an executable form for execution to learn and discover the system behavior of the designed model. Through execution, the designed model may be changed or refined to obtain the desired system behavior. As such, the design model is updated and the model compiled for execution repeatedly until reaching a desired solution. The benefit of the interactive and iterative nature between modeling and execution is reduced as the time to compile a model for execution increases.
Graphical models can also contain non-graphical language, such as executable instructions for a programming language. For example, a block diagram model in Simulink® can include instructions in the technical computing programming language of MATLAB®. Typically, these graphical models are compiled or converted into an executable form in a sequential manner on a single computer. That is, a hierarchical graphical model is compiled into an executable form by compiling each of the unit models subsequently one at a time on the same computer. The compilation process completes when the last unit model has completed its compilation process. Additionally, a single computer can be limiting to the size of the problem that can be solved, because of the relationship of the computing power of the computer to the computing power necessary to execute computing intensive iterative processing of complex problems in a reasonable time, such as compiling a large or complex model. With model compilation becoming a computing and time intensive task that may not be completed in a reasonable amount of time on a single computer, a solution to decrease the time for model loading, compilation, simulation, and code generation is desired.